[% setvar title The Perl 6 Summary for the week ending 2004-03-14 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 2004-03-14'></a><h1>The Perl 6 Summary for the week ending 2004-03-14</h1>
<p>Another week, another summary. It's been a pretty active week so, with a
cunningly mixed metaphor, we'll dive straight into the hive of activity
that is perl6-internals.</p>
<a name='Benchmarking'></a><h2>Benchmarking</h2>
<p>Discussion and development of Sebastien Riedel's nifty Parrot
comparative benchmarking script continued. Leo suggested a handy config
file approach which would allow for adding benchmarks in other
languages without having to change the script itself.</p>
<p>The initial results don't look good if you're name's Dan and you want to
avoid getting a pie in the face at OSCON though, as Dan pointed out,
there's a few tricks still to be played in this area. Anyway,
<b><i>benchmark.pl</i></b> is now in the CVS tree if you want to play with it.</p>
<p><a href='http://groups.google.com/groups?selm=200403080924.i289OAe19538@thu8.leo.home' target='_blank'>groups.google.com</a></p>
<a name='Speeling mistacks'></a><h2>Speeling mistacks</h2>
<p>The ever helpful chromatic applied Bernhard Schmalhofer's patch to fix
up an endemic speling mostake in some tests. Apparently DESCRIPTION
isn't spelt &quot;DECSRIPTION&quot;.</p>
<p><a href='http://groups.google.com/groups?selm=1078705129.15254.0.camel@localhost' target='_blank'>groups.google.com</a></p>
<a name='Dates and Times'></a><h2>Dates and Times</h2>
<p>Discussion of parrot's handling of dates and times continued this week
too. Joshua Hoblitt who works on DateTime.pm (a very handy base for
doing date/time handling in Perl 5, you should check it out) said that
the DateTime people really, really want is &quot;an epoch that's
<i>absolutely</i> fixed across all platforms.&quot;</p>
<p>There was also some discussion of where the opcode/library boundary
should be placed, with some arguing that the likes of <code>strftime</code> should
be implemented as opcodes. Melvin Smith responded to this with what
seems to me to be a very telling point: &quot;If we cannot provide a
decently performing VM that makes people want to write stuff in
bytecode (or compiled to bytecode) we have failed anyway&quot;.</p>
<p>Toward the end of the week, Dan announced some decisions and
questions. Larry had a few quibbles, but otherwise there have been no
other comments. Personally, if I never hear the phrase &quot;leap second&quot;
again, I'll not be unhappy.</p>
<p><a href='http://groups.google.com/groups?selm=8765dh4voe.wl@badger.wordzoo.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=a06010202bc74cd596e93@' target='_blank'>groups.google.com</a>[10.0.1.2] -- Dan's decisions</p>
<a name='Alternate function calling scheme'></a><h2>Alternate function calling scheme</h2>
<p>Dan has come to the view that we need an alternative, light weight,
calling convention for calling vtable opcode functions; the idea being
that this should speed up objects a tad. He asked for suggestions.</p>
<p>Leo Tötsch wasn't convinced that we really need special calling
conventions, arguing (with numbers) that it would be best to
concentrate on speeding up object instantiation by optimizing object
layout. Simon Glover agreed with him, noting that simply changing the
Array that used to store class, classname and attributes gave him a
speedup of around 15% on the object benchmarks.</p>
<p><a href='http://groups.google.com/groups?selm=a0601020cbc72593ac4bb@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='Summary Correction'></a><h2>Summary Correction</h2>
<p>Last week I said that we can't yet do delegated method calls for vtable
functions with objects. Leo pointed out that, actually, we can now. Leo
also disclaimed any responsibility for helping Brent Royal-Gordon (né
Dax?) fix up the support functions for Parrot::Config, though Brent
later claimed that he was merely the person doing the typing...</p>
<p>Jerome Quelin noted that <b><i>parrotbug</i></b> has already reached version 0.2.1
(I wonder what its version will be when Parrot 1.0.0 gets released).</p>
<p><a href='http://groups.google.com/groups?selm=200403082309.i28N9ac17099@thu8.leo.home' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=200403091942.29818.jquelin@mongueurs.net' target='_blank'>groups.google.com</a></p>
<a name='Dead Object Detection improved'></a><h2>Dead Object Detection improved</h2>
<p>Not content with his work on everything else this week, Leo has
revisited the Garbage Collector and tracked down a couple of bugs
including a really nasty sounding one that caused disappearing
continuations. He even isolated the problem with a test.</p>
<p><a href='http://groups.google.com/groups?selm=404D8D7E.4050306@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Rejigging trace output'></a><h2>Rejigging trace output</h2>
<p>Leo's rearranged the output of <code>parrot -t</code> slightly in an effort to
make it more readable. Jens Rieks was impressed and pointed out a
couple of issues, which Leo quickly fixed.</p>
<p><a href='http://groups.google.com/groups?selm=404DDAE7.8030403@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Namespaces in IMCC'></a><h2>Namespaces in IMCC</h2>
<p>Dan's day job continues to be a handy driver of Parrot
development. This time he needs to make use of namespaces and, whilst
namespaces themselves aren't completely nailed down yet, there's enough
there that the time has come to work out the syntax for working with
them in IMCC. He proposed</p>
<pre>    .namespace [foo; bar; baz]</pre>
<p>as a way of setting the current namespace to <code>foo::bar::baz</code> (in Perl
style, your language may vary). Leo was okay with that as far as it
went, but pointed out that things were slightly more complicated than
Dan's proposal implied. He suggested that the time was right to sort
out the duties of the PIR assembler towards variable names, name
mangling, lexical scopes, namespaces, globals and all that good
stuff. Dan punted slightly on this latter part, saying that, in general
it shouldn't be the assembler's job to track them. The current
namespace would simply be used as the namespace in which to place any
subsequently defined functions. There was the sound of a hand slapping
a forehead from Austria, and Leo went off and implemented it.</p>
<p><a href='http://groups.google.com/groups?selm=a06010201bc73817cf36b@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='New library, objecthacks.imc'></a><h2>New library, <b><i>objecthacks.imc</i></b></h2>
<p>In the process of redoing the Parrot Data::Dumper to use objects, Jens
Rieks built a library of helper functions to make object usage easier,
so he submitted it to the list as a standalone library. Leo checked it
in, you can find it at <code>library/objecthacks.imc</code></p>
<p><a href='http://groups.google.com/groups?selm=200403091934.50795.parrot@jensbeimsurfen.de' target='_blank'>groups.google.com</a></p>
<a name='Implementing stat?'></a><h2>Implementing <code>stat</code>?</h2>
<p>Leo Tötsch proposed a <code>stat</code> opcode for finding out about things in the
filesystem. He outlined a proposed interface. Dan agreed that we'd need
something, but that Leo's proposal was far too unix-centric to work for
a cross platform platform like Parrot. He suggested going back to first
principles and working out what information would be needed (and
possibly available). He also said that one of his guiding principles
for Parrot was that he would &quot;rather not re-implement and expose 35
years worth of 'Whoops, that turned out to be a bad idea' crud.&quot;</p>
<p>Josh Wilmes took this opportunity to remind everyone of the proposed
<b><i>miniparrot</i></b> and pointed out that, if we want it to work again, there
needs to be a smooth way to exclude opcodes or PMCs that won't work in
miniparrot's environment. Dan agreed strongly, reminding everyone that
miniparrot is intended to be the basis of Parrot's eventual build
system. (The process will go: Platform specific shell script -&gt;
miniparrot -&gt; parrot).</p>
<p><a href='http://groups.google.com/groups?selm=404EF075.8040506@toetsch.at' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=200403101753.i2AHrGYe020044@galactic.hitchhiker.org' target='_blank'>groups.google.com</a> -- Don't forget
the miniparrot!</p>
<a name='IMCC and method calls'></a><h2>IMCC and method calls</h2>
<p>Leo announced that he'd expanded IMCC's PIR parser a bit, allowing you
to write:</p>
<pre>    obj.method(args)
    ret = obj.method(...)
    (retvals) = obj.method(...)</pre>
<p>where <code>method</code> is a label.</p>
<p>A couple of hours later Dan posted a design spec for how he wanted
method calls to work in IMCC:</p>
<pre>    object.variable(params)
    object.&quot;literal name&quot;(params)</pre>
<p>Methods would be declared like:</p>
<pre>    .pcc_sub foo prototyped, method
        .param pmc foo
        .param pmc bar
        ...
    .end</pre>
<p>Declaring a method in this way would also create a local <code>self</code> which
points to the object PMC register. What do you know, Leo implemented it
all. There is also a more 'explicit' way of making method calls for
those occasions when you need more control. Check the docs/examples for
details.</p>
<p><a href='http://groups.google.com/groups?selm=404F3777.9040005@toetsch.at' target='_blank'>groups.google.com</a> -- Leo implements at 3pm</p>
<p><a href='http://groups.google.com/groups?selm=a06010206bc74fab20f4d@' target='_blank'>groups.google.com</a>[10.0.1.2] -- Dan designs at 5pm</p>
<a name='Data::Dumper test version'></a><h2>Data::Dumper test version</h2>
<p>The excellent Jens Rieks posted a test version of his object oriented
version of <code>library/dumper.imc</code> and asked for comments. (Mine was
&quot;Wow!&quot; but I didn't post it to the list 'til now). Leo wondered if he
should add it to the repository or wait for it to get rejigged to take
account of all the improved object syntax changes that had gone into
IMCC. Jens told him to hold fire until he'd converted everything to the
new syntax.</p>
<p><a href='http://groups.google.com/groups?selm=200403101412.58065.parrot@jensbeimsurfen.de' target='_blank'>groups.google.com</a></p>
<a name='Months that Do The Right Thing'></a><h2>Months that Do The Right Thing</h2>
<p>Dan's rejigged the date decoding logic to return months in the range
1-12 instead of 0-11. And there was some rejoicing.</p>
<p><a href='http://groups.google.com/groups?selm=a06010205bc7637281889@' target='_blank'>groups.google.com</a>[10.222.20.224]</p>
<a name='Problems calling methods on self'></a><h2>Problems calling methods on <code>self</code></h2>
<p>Jens Rieks discovered that he couldn't call <code>self.&quot;method&quot;(...)</code>, or
even compile it for that matter. It turned out to be a problem with the
grammar. Steve Fink provided a grammar fix, Leo tracked down a problem
with registers not getting preserved properly, and there followed some
discussion about the ambiguity of <code>.</code> being used for both method calls
and string concatenation. Luke Palmer suggested (and Melvin Smith
agreed) that it was probably better style to use the <code>concat</code> op
anyway.</p>
<p><a href='http://groups.google.com/groups?selm=200403111634.23237.parrot@jensbeimsurfen.de' target='_blank'>groups.google.com</a></p>
<a name='Object instantiation/initialization'></a><h2>Object instantiation/initialization</h2>
<p>Dan's currently seesawing about how to customize object creation by
passing arguments to the constructor function. At present, you create
an object by calling the class's <code>init</code> method, which doesn't take any
arguments, and then call an object method with appropriate arguments to
do any other setup that's dependent on the arguments if you want
to. Dan outlined three ways forward and asked for opinions.</p>
<p><a href='http://groups.google.com/groups?selm=a06010200bc7566408dbf@' target='_blank'>groups.google.com</a>[10.222.20.224]</p>
<a name='Ponie problems'></a><h2>Ponie problems</h2>
<p>Nicholas Clark posted to say that Ponie was having problems when built
using Parrot's garbage collection. After some encouragement from Leo,
he managed to write a short test case that showed the issue in a few
lines of C. Leo proposed a solution, but Nicholas and Arthur
Bergman (Ponie's core team) weren't happy with either option. This
hadn't been resolved by the end of the week.</p>
<p><a href='http://groups.google.com/groups?selm=20040311203553.GF12395@plum.flirble.org' target='_blank'>groups.google.com</a></p>
<a name='Why does Parrot have so many opcodes?'></a><h2>Why does Parrot have so many opcodes?</h2>
<p>Matt Greenwood wondered why Parrot had so many opcodes, and what the
criteria are for adding or deleting ops. Various rationales were
offered. Dan's explanation was probably the most comprehensive
though. Apparently, Parrot has opcode explosion issues because there's no
runtime op variance and if you want to know what that means, read Dan's post.</p>
<p><a href='http://groups.google.com/groups?selm=DB30501EDA9FE34CB686A124032C127E02956E01@mxgbl1.twosigma.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=a06010202bc77666a3dc0@' target='_blank'>groups.google.com</a>[172.24.18.98] -- Dan explains it all</p>
<a name='Parrot grabs SIGINT'></a><h2>Parrot grabs SIGINT</h2>
<p>Arthur &quot;Poniemaster&quot; Bergman noticed that Parrot grabs SIGINT, which
makes some of Ponie's signal handling code break. He wondered if this
was something that needed fixing, or a deliberate design decision. Dan
says that, eventually and by design, Parrot will grab all the signals,
though not necessarily in the embedded case (which is what Arthur is
using of course.)</p>
<p><a href='http://groups.google.com/groups?selm=609A6A46-7420-11D8-8D57-000A95A2734C@fotango.com' target='_blank'>groups.google.com</a></p>
<a name='Ponie gets a development release'></a><h2>Ponie gets a development release</h2>
<p>Arthur Bergman has made the second development release of Ponie, the
Perl5/Parrot hybrid. The initial response was positive.</p>
<p><a href='http://groups.google.com/groups?selm=EBE5CF35-7445-11D8-8D57-000A95A2734C@nanisky.com' target='_blank'>groups.google.com</a></p>
<a name='Per-class attribute offsets'></a><h2>Per-class attribute offsets</h2>
<p>Peter Haworth had a bunch of questions and worries about using numeric
offsets to get at class attributes. Dan tried to reassure him, but Oli
came up with a worrying corner case. Dan didn't think it was that big
an issue, but confessed that it's still a worry.</p>
<p><a href='http://groups.google.com/groups?selm=PGM.20040312181417.1806.4266@edison.ioppublishing.com' target='_blank'>groups.google.com</a></p>
<a name='Using Ruby Objects with Parrot'></a><h2>Using Ruby Objects with Parrot</h2>
<p>Poor old Dan; once you've got some bits of objects done, it just means
everyone wants more from you. Mark Sparshatt wondered how to handle
languages like Ruby, where a class is also an object, which seems to
run counter to Parrot's scheme using ParrotClass and ParrotObject PMCs
where a ParrotClass isn't a ParrotObject. He suggested three ways
forward.</p>
<p>Summarizing this stuff is Hard. One one level you can reduce the issue
to a couple of sentences, but understanding those sentences involves
rather a lot of underpinning knowledge that I'm not sure I have. I just
know that life's an awful lot easier if I can treat classes as objects.</p>
<p>Dan tried to wrap his head 'round things and posted a summary of his
initial understanding of what a metaclass is. He wondered if we'd need
to have a 'call class method' operation. Paolo Molaro pointed out that
most of this stuff only becomes a real issue when you have to deal with
objects implemented in one language calling methods on objects
implemented in a different one. Leo Tötsch explained Parrot's current
(somewhat confusing to these eyes) hierarchy where:</p>
<ul>
<li><a name='A ParrotClass isa delegate PMC'></a>A ParrotClass isa delegate PMC</li>
<li><a name='A ParrotObject isa ParrotClass'></a>A ParrotObject isa ParrotClass</li>
<li><a name='A HLL class isa ParrotClass and a low-level PMC object'></a>A HLL class isa ParrotClass and a low-level PMC object</li>
<li><a name='A HLL object isa all of above'></a>A HLL object isa all of above</li>
</ul>
<p>Piers Cawley thought that having ParrotObject inherit from ParrotClass
rather than vice versa seemed somewhat perverse. He also argued that
method dispatch should be decoupled from method lookup. I think he and
Leo failed to communicate.</p>
<p>Mitchell N Charity was good value on all this as well; definitely worth
reading if you're into the theory behind OO should work.</p>
<p><a href='http://groups.google.com/groups?selm=4052382E.30108@yahoo.co.uk' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=a06010211bc78efbdadc4@' target='_blank'>groups.google.com</a>[172.24.18.98]</p>
<p><a href='http://groups.google.com/groups?selm=200403141936.i2EJaog10368@vendian.org' target='_blank'>groups.google.com</a> -- Mitchell N Charity on
Objects, Classes and MetaClasses</p>
<a name='Configure changes'></a><h2>Configure changes</h2>
<p>Brent announced that he's been making some significant changes to
Configure in the last week or so. He posted a big list. Leo liked what
had been done so far, but thought the process needed more steps to
probe for more stuff.</p>
<p><a href='http://groups.google.com/groups?selm=4052638F.9020806@brentdax.com' target='_blank'>groups.google.com</a></p>
<pre>=head PIR Syntax changes</pre>
<p>Leo announced that he's added some syntactic sugar to PIR; you can now
write:</p>
<pre>    $N0 = sin 0
    $I0 = can $P0, &quot;puts&quot;
    $I0 = isa $P0, &quot;scalar&quot;</pre>
<p>etc, and they'll be magically converted to</p>
<pre>    PARROT_OP lhs[, args]</pre>
<p>which is rather handy (with some ugly cases: <code>P1 = invoke</code> being the
example Leo came up with).</p>
<p><a href='http://groups.google.com/groups?selm=405428FD.60608@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='OO version of Data::Dumper'></a><h2>OO version of Data::Dumper</h2>
<p>On Sunday, Jens Rieks released his OO version of Data::Dumper, along
with a couple of helper libraries, including a rewritten
<b><i>objecthacks.imc</i></b>, now called <b><i>objects.imc</i></b>. Leo committed it (and a
followup bugfix) promptly and Parrot now has its first OO
application/library. Yay Jens!</p>
<p><a href='http://groups.google.com/groups?selm=200403141744.41872.parrot@jensbeimsurfen.de' target='_blank'>groups.google.com</a></p>
<a name='Meanwhile, in perl6-language'></a><h1>Meanwhile, in perl6-language</h1>
<a name='Magic blocks'></a><h2>Magic blocks</h2>
<p>Remember last week I implied that magic UPPERCASE blocks for things
like <code>BEGIN</code>, <code>CHECK</code>, <code>INIT</code> etc were being replaced by properties
on variables? Well, I was wrong. We keep magic blocks but we also get
handy properties for attaching actions to variables.</p>
<p>In fact, the handy properties were first discussed in April last year,
as Larry pointed out.</p>
<p><a href='http://groups.google.com/groups?selm=20040309002351.GA10938@wall.org' target='_blank'>groups.google.com</a></p>
<a name='Mutating methods'></a><h2>Mutating methods</h2>
<p>Juerd wondered about the possibility of mutating and non mutating
methods in Perl 6. Consider the Perl 5 functions <code>chomp</code> and
<code>lc</code>. <code>chomp</code> potentially modifies its argument, whereas <code>lc</code>
returns a new string. Juerd liked the idea of having mutating and
non mutating versions of both <code>chomp</code> and <code>lc</code> (and other such string
methods). He proposed using</p>
<pre>    $aString.lc; # Non-mutating
    $aString.=lc; # Mutating</pre>
<p>The general response to this was favourable.</p>
<p>The thread sparked a discussion of Perl 6 Rules and hypothetical
variables (which just makes me hope Damian gets Perl6::Rules written
really soon).</p>
<p>Larry posted a chunk of stuff from the forthcoming Apocalypse 12 that
looks rather neat. Then he and Simon Cozens started talking Japanese
and my head started spinning.</p>
<p><a href='http://groups.google.com/groups?selm=20040310163933.GB10971@c4.convolution.nl' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=20040312200110.GA2793@wall.org' target='_blank'>groups.google.com</a> -- Larry tells us more about A12</p>
<a name='Operators that keep going and going...'></a><h2>Operators that keep going and going...</h2>
<p>Carissa wondered if Perl 6 would have what she called 'persistent'
operators, so that you could do:</p>
<pre>    my $a = 10;
    my $b = 5;

    my $c = $b + $a;
   
    print $c; # 15
   
    $a = 8;

    print $c; # 13</pre>
<p>Several people pointed out that it's already possible to do this sort
of thing in Perl 5 so it'd be a big surprise if you couldn't do the
same thing in Perl 6. (See perldoc overload in the section &quot;Really
symbolic calculator&quot; for details).</p>
<p><a href='http://groups.google.com/groups?selm=KKEPICKEKBFIGENPCEJIIEKDCAAA.c_nikkel@shaw.ca' target='_blank'>groups.google.com</a></p>
<a name='Announcements, Apologies, Acknowledgements'></a><h1>Announcements, Apologies, Acknowledgements</h1>
<p>I've had it with discussions of whether Unicode's a good idea or not,
and from this summary onwards I'll not be including any such discussions
unless Larry does an implausible <i>volte face</i>. That is all.</p>
<p>Now I can go back to being anxious about my stepdaughter who's been in
labour for rather a long time.</p>
<p>If you find these summaries useful or enjoyable, please consider
contributing to the Perl Foundation to help support the development of
Perl. You might also like to send me feedback at
mailto:<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>, or drop by my website, maybe I'll
add some content to it this week.</p>
<p><a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> -- The Perl Foundation</p>
<p><a href='http://dev.perl.org/perl6/' target='_blank'>dev.perl.org</a> -- Perl 6 Development site</p>
<p><a href='http://www.bofh.org.uk/' target='_blank'>www.bofh.org.uk</a> -- My website, &quot;Just a Summary&quot;</p>
</div>
